Codecov Report

Merging #160 (342ec02) into main (ec64bcb) will increase coverage by 0.17%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #160      +/-   ##
==========================================
+ Coverage   93.38%   93.56%   +0.17%     
==========================================
  Files          11       11              
  Lines        1678     1678              
==========================================
+ Hits         1567     1570       +3     
+ Misses         78       75       -3     
  Partials       33       33              

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@shizhMSFT can you PTAL?

EdDSA is sadly more ambiguous.

Internally I suggest a more specific name like Ed25519EdDSA... externally you will need to comply with the standards.

Presently there’s no way to negotiate Ed448 because the alg is just EdDSA, and it was already claimed to be Ed25519...

This has awful consequences for things like WebAuthN / Passkeys, etc....

Since @OR13 mentioned this to me, I'll leave a reference to one issue on this open problem within the WebAuthn issue w3c/webauthn#1446 . A more relevant section of the Editor's Draft: https://w3c.github.io/webauthn/#sctn-alg-identifier

There has been a few faint discussions of having an additional registry of integer 'fully parameterized algorithm' values in the past which I can't find reference to at the moment. Not sure if this would be WebAuthn-specific or live within COSE. WebAuthn does not currently have intention to expand beyond representing negotiation of algorithms as a list of integer values.

Creating pure non-polymorphic "alg" values for JOSE and COSE that fully specify their parameters has been on my to-do list for a while. This is needed for lots of systems that use "alg" to determine the cryptographic operation to be performed. WebAuthn/FIDO2 and OpenID Connect are just a few prominent examples.

Note that when I wrote RFC 8812, I explicitly prohibited using the potentially polymorphic COSE algorithm identifier ES256 for ES256K signatures. See this text at https://www.rfc-editor.org/rfc/rfc8812.html#name-other-uses-of-the-secp256k1:

When used for ECDSA, the secp256k1 curve MUST be used only with the ES256K algorithm identifier and not any others, including not with the COSE ES256 identifier. Note that the ES256K algorithm identifier needed to be introduced for JOSE to sign with the secp256k1 curve because the JOSE ES256 algorithm is defined to be used only with the P-256 curve. The COSE treatment of how to sign with secp256k1 is intentionally parallel to that for JOSE, where the secp256k1 curve MUST be used with the ES256K algorithm identifier.

@qmuntal It becomes harder to review if those file conflicts are not resolved.

This PR targets the branch keyapiimpr. Is it intended?

@qmuntal It becomes harder to review if those file conflicts are not resolved.
This PR targets the branch keyapiimpr. Is it intended?

Fixed. @shizhMSFT